HyperLib 1997 Winter - Disc 1/HYPERLIB-1997-Winter-CD1.ISO.7z/HYPERLIB-1997-Winter-CD1.ISO/オンラインウェア/UTIL/Menu Events 1.3 folder.sit/Menu Events 1.3 folder/Menu Events 1.3/Menu Events Help.rsrc/STR#_1027.txt

Text File | 1996-03-06 | 7KB | 281 lines

□

□

recorded.□

selection, it does not cause a Select Menu Item script command to be

NOTE:  While receiving a Select Menu Item event does simulate a menu

□

recorded, but should work as usual.□

selections, try again with the Caps Lock key up.  The command will not be

If an application seems to be misinterpreting or not receiving menu

□

release the Caps Lock key, to suppress the recording capability.□

duplication, you can use the item窶冱 Command-key equivalent (if any), or

two commands when you select an item from its menus.  To prevent this

If the application is scriptable in its own right, a script editor may record

□

□□□□□

be processed in the usual way.□

Whether or not it succeeds in recording the event, the menu selection will

command.  A gentle 窶徼wang窶 sound confirms that this has happened.

pressed), so that a script editor can record the event as a script

selection (including parameters for any modifier keys which were

Menu Events will create a Select Menu Item Apple event to represent the

if the Caps Lock key is down at the time you release the mouse button.

where Menu Events is installed, menu item selection behavior is modified

When you are using a high-level-event-aware application on a machine

□

□□□□xApple Event Recording Capability□

□□□□□

□

□

to do program linking unless Menu Events is locked.□

remote program linking.  In particular, guest users should not be allowed

should be careful about which users and applications are enabled for

IMPORTANT NOTE:  Users of machines where Menu Events is installed

□

Events at startup shows whether or not the lock is in effect.□

remote sender to require user interaction.  The icon displayed by Menu

because most will assume the default interaction state, not expecting any

necessary for Menu Events to be useful with most target applications,

that events sent from a remote machine are not rejected.  This trick is

the default value, it will momentarily change it to kAEInteractWithAll, so

it sees that the user interaction state is kAEInteractWithLocal, which is

processes can be controlled by remote senders.  If it is not locked, and if

only target applications which explicitly allow interaction with all

If the Menu Events extension is locked, using Finder窶冱 Get Info dialog, then

□

application).□

Users & Groups (permission to user), and Finder窶冱 Sharing (permission to

usual program linking checks apply, namely, Sharing Setup (on/off),

If the sending and receiving applications are on different machines, the

□

the event.□

other process, the Menu event handler will respect that state, and refuse

kAEInteractWithSelf, where it disallows interaction requested by any

If the target application is in that rare user interaction state,

□

target application before sending it a Menu event.□

time.  Another approach would be to call SetFrontProcess to activate the

Menu event, if there is any chance that it will be in the background at the

user interaction, it should call AEInteractWithUser before sending the

posted anyway.  Since your sending program is indirectly instigating a

the kAECanSwitchLayer flag has no effect, and the notification request is

If both the sending program and target application are in the background,

□

wait state, disrupting its usual background event processing behavior.□

receives a Menu event with this flag not set, it may go into a notification

notification request.  If the target application is in the background, and

target application to come to the front without having to post a

interaction.  It should also set the kAECanSwitchLayer flag, allowing the

flag in the sendMode parameter to AESend, in order to achieve user

The sending program must set the kAECanInteract or kAEAlwaysInteract

□

□□□□□

when it sees a mouse-down event.□

target application to the front, where an application always expects to be

if it did, it would still have to request user interaction just to bring the

know which menu selections will really require user interaction, but even

joint sender/receiver control over user interaction.  Menu Events doesn窶冲

The Apple Event Manager implements a complicated but sensible model for

□

□□□□xUser Interaction Policy□

□□□□□

□

□

unknown Apple event, as it should.)□

a problem if it returned errAEEventNotHandled when faced with an

classes, preventing Menu Events from working.  (The handler wouldn窶冲 be

applications, for example, bind their own handler over all Apple event

rather than some handler supplied by the application.  Many Microsoft

includes a null 窶徼attoo窶 parameter to prove that it handled the event,

NOTE:  When replying to any of the three event types, Menu Events

□

as though the user had actually made the selection.□

selected.  The patches then remove themselves.  From there, it is exactly

specified.  The patched traps tell the application that the given item was

simulate another mouse click in the menu bar, with modifier keys if

Sixth (in the case of a Select Menu Item event), it posts an event to

□

enable/disable flags are set in the normal fashion.□

items may differ from the norm.  Menu Events assumes that the count and

non-standard menu definition procedure, its way of counting or disabling

noSuchMenuItemErr, or menuItemDisabledErr.  If the menu has a

menu item is valid and enabled.  If not, it returns noSuchMenuErr,

Fifth (in the case of a Select Menu Item event), it verifies that the given

□

menus up to date.□

themselves.  This step is solely to ensure that the application brings its

application that no menu item was selected.  The patches then remove

the menu bar, with modifier keys if specified.  The patched traps tell the

Fourth, if everything is OK, it posts an event to simulate a mouse click in

□

Menu event is still pending, it returns menuEventPendingErr.□

If it finds that the patches are already in place, meaning that an earlier

Third, it patches some traps so that it can gain control of menu bar clicks.

□

in normal operation.  If it is refused, it returns errAENoUserInteraction.□

menu bar click while it is in the background, something that never happens

interaction, because it could be dangerous to feed the target application a

Second, it asks for the application to be brought to the front for user

□

noSuchMenuErr.□

First, it verifies that the given menu is valid.  If not, it returns

□

happen, but the event handling is more complex.□

When you send a Query Menu or Select Menu Item event, the same things

□

□□□□□

before.□

application stays in the background or in the foreground, wherever it was

basis of the application窶冱 menu list structure.  Through all of this, the

event handler provided by Menu Events forms a reply to the query on the

the resulting high-level event as an Apple event without looking at it.  The

When you send a Query Menu List event, the ideal application dispatches

□

□

□□□□□□□ﾃ･□□□How Does Menu Events Work?□

□□□□□□窶ｹ□

□□□□□□窶ｹ

□

□□□□□